Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-201 < prev next >

Wrap

Text File | 1988-12-01 | 17.7 KB | 326 lines

Internet Experiment Note No. 201 INTERNET SHORT-TERM SERVICE GOALS David D. Clark MIT Laboratory for Computer Science Computer Systems and Communications Group 1. Introduction The purpose of this document is to identify the milestones which must be met in order to bring the current internet architecture to a stable service which can be used while the next round of research development is undertaken. This document describes the functionality associated with the service to be offered, and identifies the work to be done in order to achieve that function. This document discusses all aspects of the internet service, and is intended for planning purposes within the internet research community. More detailed documents are available as RFC's that discuss the specifics of host conversion from NCP to TCP. This document should be viewed in the larger context of the long-term project planning which is now underway. An assumption underlying this document is that it is necessary to identify carefully a service which we will provide in a stable form at this time, in parallel with which a follow-on enhanced capability will be designed and implemented in selected hosts and gateways. This current service should more or less mimic the quality of service provided today on the ARPANET by the NCP protocol, in terms of supported application protocols, reliability, responsiveness, etc. 2. Service Milestones There are five major milestones in the achievement of the current service offering. Two of these relate to support of TCP on the ARPANET. The other three relate to support of actual internet traffic. These milestones are as follows: 1. First use of internet for service (now happening!) 2. NCP quality support for first TCP-only host on ARPANET (July 1982) 3. NCP quality service for internet (?) 2 4. Heavy load on internet (?) 5. Last NCP host removed from ARPANET (January 1983) These five milestones are explained and elaborated in the following paragraphs. 3. Milestone One: Minimal Support for Internet Service Internet service is being used today, as part of the Fort Bragg packet radio demonstration and by the machines at COMSAT, which are not connected directly to the ARPANET. I would characterize the service currently available to these users as somewhat less than minimal, in that it works only because certain special case adjustments have been made to individual hosts. There are three important components to this milestone: a. Fragmentation and reassembly must be completely implemented through the internet. It is repeatedly brought home that the failure to implement this portion of the protocol causes important and substantial confusion. At the last internet meeting, the failure of the TIU to support reassembly once again prevented machines which sent jumbograms from being used. There is no justification for continuing to sidestep this problem. b. Name tables on operational hosts must be upgraded so that they have both the structure and capacity to name all of the hosts in the internet. In the long term, we hope that it will not be necessary for every host to maintain a complete internet table, since we postulate the existence of name servers to which an individual host can turn to convert a name to a number. However, name servers are not currently available, and the requirement for this name conversion is immediate. c. ICMP must be supported. Without ICMP, one cannot achieve even a minimal level of error recovery. These subtasks must be completed quickly, because minimal service is important for the sites in Europe who are momentarily being removed from the ARPANET. If the only requirement of the European community is user telnet, then the name table problem on server hosts such as TOPS 20 can be momentarily sidestepped, but the lack of fragmentation will prove totally unworkable, as it already has. 3 4. Milestone Two: NCP Quality Support for TCP on ARPANET Today, there exist hosts on the internet that speak only TCP. However, these hosts are very substantially limited as to what they can do. The intent of this milestone is to define a point at which a TCP-only host connected to the ARPANET can obtain a level of service to all other hosts directly connected to the ARPANET that it might achieve using NCP today. This goal is for the ARPANET only, not the general internet. This restriction is important, because it defines the point at which a host converting from NCP to TCP can obtain a reasonable service to other hosts to which it previously had NCP access. In order to achieve this goal, there must be conversion facilities available so that the TCP host can communicate with NCP-only hosts, and symmetric conversion routines must be available to permit NCP only hosts to have access to the TCP host. The exact function required for conversion in each direction is slightly different, since the protocols available on the TCP side are sometimes somewhat more powerful, as in SMTP, and we are interested in providing a better level of service for the TCP only host than we are for the unconverted NCP only host. The specific requirements for this milestone are: a. Telnet forwarding in both directions. This is a machine which speaks both TCP and NCP, to which a user can log in using one protocol and then request an outgoing telnet connection using the other protocol. b. FTP staging facility. It appears to be rather difficult to build an automatic facility for linking two FTP transfers together end to end. The FTP syntax is not rich enough so that one can describe to a forwarder where the ultimate destination of the transmission is to be. Thus, since this is only a transition mechanism, it seems sufficient to create an FTP facility which is operated manually. First the user transfers this file to an intermediate point, and then he manually logs in to this intermediate point (or to the final destination machine) to transfer the file to its ultimate destination. c. Mail forwarding. This is a very important facility, since mail is a very important part of the day to day business of the ARPANET, and because it will be a highly visible means by which we will make conversion to TCP popular. SMTP has been specifically implemented to make possible the use of forwarders to provide automatic protocol conversion. As originally proposed, automatic forwarding of mail was to be implemented by causing every host on the ARPANET, whether or not it supported TCP, to implement SMTP by this milestone. It is not clear that universal conformence can be achieved. I propose that this strategy be modified to permit an alternative in which a more 4 sophisticated forwarder will permit mail to flow from an NCP to a TCP host if the sender of the mail manually constructs a special destination string which triggers forwarding. In order to achieve SMTP service, the following sub-milestones must occur. First, the definition of the protocol must be stabilized. This is now being done. Secondly, mail forwarders must be implemented and brought to a service level. d. The TCP-only hosts must be identified and brought to a full, functional level. Full function includes the following: -IP -ICMP -TCP -TELNET(User, Server) -FTP(User, Server) -SMTP(Sender, Receiver, Composer) As part of implementing this rather ambitious list of protocols, it is important to identify and eliminate certain popular deficiencies which appear in some existing implementations. For example, the structure which exists between the protocol layers for reporting errors must be rich enough that network conditions such as host-dead or imp-dead correctly terminate the network connection with the appropriate message for the user. For another example the name table must be upgraded from an ARPANET only to an internet facility. There is a great deal of work implied by the above list. Currently none of the forwarders, either TELNET, FTP, or SMTP, exist except in experimental forms, and it is not clear that these experimental forms in fact provide the basis for a service offering. This milestone is seven months away, and it will require prompt effort to achieve it. It is not the purpose of this milestone to encourage (or permit) a "preliminary" host implementation suitable only for the relatively benign ARPANET environment. The host implementor should be working toward all of these goals at once. It is in the networks that these milestones can be distinguished. 5 5. Milestone Three: NCP Level Service Over Internet This is a somewhat vague milestone, and items which appear only on this list have a habit of being repeatedly postponed in task schedules. Nonetheless, this is an important goal, because it will establish the point at which we can stop tinkering with the service we provide and proceed on to the next level of design. It is important not to include too many items in this list, less the list grow so big that we never complete its implementation. On the otherhand, if we do agree to include something on this list, then we must be consistent and sincere about implementing it in all the relevant machines. Partial implementation is not a useful middle ground. The following functions are nominated for this category. a. Robustness features. Included in this category are replication of hardware to provide an alternative path in the case of a single component failure. This is particularly important in the SATNET link to Europe. Dual gateways may be required in other locations, where important acces nets enter the transport core. b. Fault detection and isolation. "Dissapearing packets" are still an overly common aspect of internet communication. It is important that every host be equipped with suitable tools to detect and, to the extent possible, recover from internetwork outages. At a minimum, all hosts must use the ICMP facilities of host unreachable and redirect to recover from gateway outages or at least notify the user that further communication is impossible. It is also important that tools be put in place so that proper repair procedures are instituted properly when a portion of the internet fails. c. Proper handling of option fields in the protocols. Currently, options are most commonly processed by ignoring them. We must decide which options we are really serious about and implement them. An obvious topic for discussion is the set of options that deal with the source route function. This is a good example of where we must do an all or nothing implementation. Isolated implementation of source route is demonstrably useless. d. Access control. Certain mechanisms for controlling access to the internet must be implemented as part of the interim service. At a minimum, these include login features in the TAC. It may be necessary to implement some further controls inside the gateway, but as yet no one has conceived of what those mechanisms could be. This topic requires consideration. e. Name servers. The number of hosts, and thus the number of names in 6 the internet is much larger than that of the ARPANET. Many name tables are overflowing. One way to avoid this problem is by providing name servers to which a host can turn in order to translate an unknown name into an internet address. In some respects, a namer server is a very simple mechanism, but it is very easy to develop a name server mechanism which is so complicated as to be unrealizable. Some firm decision must be made as to the level of service to be provided by name servers in the internet, and then to provide an implementation strategy whereby name servers are universally available. 6. Milestone Four: Heavy Traffic Over the Internet This is difficult milestone to quantify, since we do not know the rate at which traffic will build up, nor what maximum traffic level we must support. Nonetheless, it seems clear that the existing gateway implementations will not support the expected load. There are three improvements which have been proposed to address this topic. All of these depend on replacement of existing gateways with C/70 gateways or recoding of the existing software, so that there is additional space available. a. Upgrade the net interface software so that it shows more intelligence about interacting with the support network. For example, the driver for the ARPANET should count RFNMs, and the driver for the SATNET should interact properly with the selective refusal mechanism of the SATNET's non blocking interface. b. More buffers in the gateway. c. Improved instrumentation in the gateway, so that it is possible to determine where bottlenecks are. In addition to gateway tuning, we need to achieve a minimum level of TCP "good behavior". The occurrence of Silly Window Syndrome under heavy load must be avoided, or the net will clog up totally. Hosts must provide sufficient buffering to obtain reasonable throughput under long-delay situations. Finally, we must begin to plan for substantial congestion control problems in the internet. The existing algorithm, which is based on a source quench message from the gateway to the host, has not been shown to work well. In the short run, we have not identified any alternative mechanism which will work better. At a minimum, every host and gateway should implement ICMP, so that source quench messages can at least be sent and received. More work is required in this area to determine what the proper action should be. 7 Milestones three and four are closely related, and could have been combined. The distinction is that milestone three contains things that must be done even if the offered load is small. Adequate performance may depend on new gateway hardware, which may delay milestone four. If this is so, users will be interested in milestone three as a separate goal. 7. Milestone Five: NCP Service is Discontinued in the ARPANET This milestone has occasionally been described as a very important one for the internet implementors. In fact, most of the work necessary at the internet level to achieve this goal will have been done as part of the previous milestones. There are essentially two important subcomponents of this milestone: a. The TCP TAC must be deployed. This is very important, and should be done somewhat in advance of this actual milestone to allow for the following point. b. Facilities for testing and debugging new TCPs must be conveniently available on the ARPANET, so that hosts converting from NCP to TCP can verify the correct operation. The major effort in achieving this milestone is the implementation of the previously itemized list of protocols on every host attached to the ARPANET. This task will require substantial effort, but this effort is provided by the system maintainers for the systems in question. Our responsibility is to provide the proper support for those implementors. In addition to the testing and debugging facility provided above, the other important requirement is informal documentation that provides help and guidance to implementors beyond the actual protocol specification. A number of ways have been proposed to provide this informal help. One easy strategy is to distribute a collection of TCP design documents for the TCPs that have already been implemented. I am currently preparing a number of reports that attempt to gather together the insights about TCP and IP which are well understood in the implementation community but may not be obvious to first time implementors. First topics include strategies for reassembly and packet resequencing, management of window and acknowledgement algorithms, and proper management of names, addresses, routes, and ports. Anyone wishing to contribute to this work should contact me. A table of contents will be out soon. There are a large number of preliminary milestones associated with the upgrade of all ARPANET hosts to TCP, such as document distribution, and interaction with the various host maintainers, and managers. These subgoals are not outlined in this document, but are described in a separate document recently released by Jon Postel. 8 8. Priorities The preceding discussion of the five service milestones has presented a rough outline of subtasks necessary to achieve these five goals. A separate project milestone document, now being prepared, lists these individual tasks in a more structured form, and provides dates and probabilities of success where known. -------